昨天談到：
一棟建築裡可能有幾百、幾千個 Point。
如果 AI 連每一個 Point：
代表什麼、
在哪裡、
屬於什麼 Device、
具備什麼 Capability，
都還沒有弄清楚，
就沒有資格直接控制。
所以第一步是：
Site Knowledge
但假設有一天，
這些基本資料真的開始整理好了。
Sol 知道：
這是會議室。
現在有人。
這是溫度 Sensor。
這是 CO₂ Sensor。
這一套 HVAC 服務這個 Space。
那我是不是就可以直接跟她說：
「Sol，把會議室變舒服一點。」
然後讓 AI 自己去控制？
我的答案仍然是：
不可以直接這樣接。

因為「舒服」這兩個字，
對人來說很自然。
對 Physical Control 來說卻非常模糊。
舒服是：
24°C？
26°C？
濕度下降？
CO₂ 降低？
提高新風？
降低風速？
調整窗簾？
還是什麼都不要動？

甚至同一句：
「有點熱。」
都不一定是一個 Action Request。
可能只是：
描述。
抱怨。
詢問。
或者希望 Sol 先分析原因。
如果 AI 把任何一句自然語言，
都直接翻譯成：
Control Command
那其實非常危險。

這也是我現在非常堅持的一句話：
Natural Language is intent.
Not authority.

自然語言可以幫我們描述：
人想要什麼。
但它不能自己完成：
Identity。
Authority。
Scope。
Policy。
Safety。
State Validation。

所以如果 Ronnie 說：
「Sol，把會議室變舒服一點。」
我現在希望 System 第一個做的事情，
不是立刻決定：
把冷氣調到幾度。
而是先問：
Human 到底想要什麼？
這就是：
Intent。

例如 Intent 可能是：
改善 Thermal Comfort。
改善 IAQ。
減少悶熱感。
但這跟：
「立刻把某一個 Setpoint 改成 20°C」
完全是兩回事。

再往下一步，
還需要：
Reality Context
現在室內真的熱嗎？
溫度多少？
濕度多少？
CO₂ 呢？
有多少人？
外氣條件如何？
設備現在有沒有 Alarm？
目前是不是 Maintenance Mode？
如果 Reality Context 都沒有，
那 AI 就只是在：
猜。

然後還要問：
Identity
這句話是誰說的？
Ronnie？
一般使用者？
訪客？
Maintenance Engineer？
不同身份，
可以有不同 Capability。

再來：
Authority
這個 Human 有沒有資格要求：
改 Comfort Setpoint？
改 HVAC Mode？
解除 Energy Constraint？
甚至碰到更高風險設備？

接下來：
Policy / Governance
即使 Human 有 Authority，
也不代表所有要求都應該直接通過。
例如：
現在有 Demand Limit。
設備有 Safety Constraint。
IAQ Policy 不允許關閉新風。
某個設備正在 Maintenance。
那 Human Intent 還需要受到 Policy Boundary 約束。

再來才是：
Capability
這個 Site 到底能做什麼？
也許這個房間：
可以調整 Setpoint。
但不能控制風量。
另一個場域：
只能 Read。
另一套設備：
甚至沒有可安全 Write 的 Interface。
AI 不能因為：
「我知道理想解法」
就假設現場具備那個 Capability。

所以整條 Target Architecture，
我們現在會描述成：
Natural Language
↓
Intent
↓
Reality Context
↓
Identity
↓
Authority
↓
Policy / Governance
↓
Capability
↓
Governed Action Gateway
↓
Connector
↓
Physical System
↓
Verified Outcome

這裡我要再次強調：
這是一條：
Target Architecture
不是我今天在文章裡宣稱：
AICAN 展示中心所有 Physical Action 已經全部照這條路 Production Enforcement。
還沒有。

但這條架構對我非常重要。
因為它把：
「人怎麼講話」
跟：
「機器最後怎麼動」
正式分開。

以前做 Automation，
我們常常會很靠近設備層思考。
例如：
這個 Modbus Register 寫多少？
那個 BACnet Object 改什麼值？
MQTT Topic 要送什麼？
這些當然都是重要工程。
但到了 AI Layer，
我反而希望它不要太早碰這些東西。

AI reasoning layer 不應該第一個思考：
「我要寫哪個 Register？」
它應該先確認：
「這件事情現在應不應該發生？」

真正到了 Connector，
才處理：
這個 Intent 要怎麼被轉成：
BACnet。
Modbus。
MQTT。
KNX。
HTTP。
或其他設備協議。

這樣的分工有一個很大的好處。
Intelligence 不需要被綁死在 Protocol。
今天底層是 BACnet。
明天換成 Modbus。
另一個 Site 用 KNX。
上層的：
Human Intent。
Reality。
Authority。
Governance。
不需要全部重寫。
這也是我一直希望 AICAN 保持 Vendor-neutral 的原因。

我真正想建立的，
不是：
「Sol 會操作某一個品牌。」
而是：
Sol 知道自己什麼時候有資格要求某個 Capability 被執行。
至於最後怎麼執行，
交給：
Connector。
Controller。
BMS。
PLC。
既有 Automation Layer。
這些更適合負責 Deterministic Execution 的系統。

也就是：
AI 可以 Reason。
Governance 決定 Action 能不能通過。
Connector 負責轉譯。
底層 Controller 負責真正的控制。
我現在越來越不想讓：
LLM = PLC
因為這兩種系統的責任根本不同。

這件事情其實也回到：
Day 05 的 Human Authority。
Day 15 的 Fail Closed。
Day 20 的 Physical Trust Boundary。
現在我們只是把它們真正串到一起。

我覺得這也是 Physical AI 很容易被 Demo 掩蓋的地方。
Demo 最吸引人的通常是：
Human 說一句話。
AI 回一句話。
燈亮。
看起來中間什麼都沒有。
但如果未來真的要走進：
住宅。
商辦。
醫院。
工廠。
車。
我反而希望：
中間有很多看不見、但非常清楚的 Gate。
因為那些 Gate 才是：
真正讓我敢把 Action 交出去的原因。

所以 Day 23 最後，
我會把這件事情濃縮成兩句。
第一句：
Natural Language is intent, not authority.
第二句：
Natural language should never directly become physical execution without governance.

而當 Physical Action 未來真的被允許並執行以後，
故事還沒有結束。
假設 Sol 說：
「我幫你把空調最佳化了。」
甚至說：
「節能 20%。」
我下一個問題一定是：
真的嗎？
Command Sent，
不代表 Reality Improved。
API 200，
也不代表 Energy Saving。
Day 24，
我們來談 Physical AI 很容易被忽略的最後一段：
AI 說節能 20%，我為什麼不能直接相信？